Benchmarking persistent programming languages: quantifying the language/database interface

A motivating factor in the development of object-oriented databases is that they reduce the impedance mismatch [Copeland and Maier 1984] between programming languages and database systems. One benefit is that a straightforward mapping between the type system of the programming language and that of the database reduces the conceptual barrier for the developer’s of database applications. Object-oriented databases also represent an opportunity for more efficient implementation of the language/database interface, since it is possible for the type system of the language to make guarantees about the safety of programs executing against the database. A type-safe program can freely manipulate permanent data without fear of corrupting the database – the type system guarantees it. Thus, there is no need for an unwieldy interface between program and database for the manipulation of data. So long as mechanisms exist to make database objects directly available to the program in memory, the program can access and modify that data directly, without making calls to the underlying database system. In effect, data are cached by the application program for efficient manipulation. Persistent programming languages [Atkinson et al. 1982; Atkinson, Chisholm, Cockshott, and Marshall 1983; Atkinson, Bailey, Chisholm, Cockshott, and Morrison 1983; Atkinson and Buneman 1987] epitomize this ideal by viewing the database as a stable, persistent, extension of volatile memory, in which data may be dynamically allocated, but which persists from one program invocation to the next. The language allows traversal and modification of the persistent data structures transparently, without explicit calls to read and write the data. Rather, the language implementation and run-time system contrive to make persistent data resident in memory on demand, much as non-resident pages are automatically made resident by a paged virtual memory system. Moreover, a persistent program can modify persistent data and commit the modifications so that their effects are permanently recorded in persistent storage. Atkinson, Bailey, Chisholm, Cockshott, and Morrison [1983] characterize persistence as “an orthogonal property of data, independent of data type and the way in which data is manipulated”. This particular characterization has important ramifications for the design of persistent programming languages, since it encourages the view that a language can be extended to support persistence with minimal disturbance of its existing syntax.